Electronic commerce, often known as “e-commerce,” includes the buying and selling of products or services over electronic systems such as the internet. The amount of trade conducted electronically has grown immensely with the widespread adoption of internet technology. One particularly explosive area of growth in e-commerce is in the field of advertising and, in particular, video advertising on the Internet.
Typically, there are three entities involved in online video advertising. Content and service providers, such as websites, software applications (“apps”), and the like are often referred to as “publishers.” Persons using network-connected (“connected”) video player devices, such as computers and smart mobile devices, to access publisher content and/or services are referred to variously as “users”, “clients”, “audience”, “visitors”, “eyeballs” and the like. Those who wish to place ads with publishers to be viewed by users are referred to as “advertisers.” The amount of resources (e.g. physical space, time, etc.) available for video advertising is sometimes referred to as “inventory.”
There is competition by publishers for advertisers and entities that represent advertisers. That is, since many advertisers are represented by ad agencies, ad networks, and/or other entities managing the distribution of advertising (collectively “ad networks” or “advertisers”) this competition for advertisers extends to such entities. Since most publishers offer some form of fee splitting arrangement with ad networks, some of this competition may be reflected by the profit margins they offer to ad networks. It is therefore important for ad networks to provide accurate user and device interaction data with respect to the advertisements that they place and to optimize the operation of video player devices. While some of this data can be derived by a user's interaction with one or more ad servers, there has been increasing amount of attention to the development of Software Development Kits (“SDKs”), which reside on the video player devices and integrate with the video player software to monitor and enhance the performance of the video player devices with respect to the display of video ads. For example, SDKs can be used to affect the timing, nature, delivery and display of video ads.
In general, an SDK is typically a set of tools and protocols which allows for the enhancement of software and/or hardware platforms. In the context of video advertising on, for example, personal computers, laptop computers, tablets, smartphones, Smart-TVs and the like, an SDK is often used to configure a software video player to support a particular advertising platform. For example, an advertiser (such as an advertising network) can provide a publisher (such as a company's website or an application or “App” developer) with an SDK that is specific to that advertiser. In the case of a website publisher, the SDK can be integrated into its video player for delivery to a user's device over a network, such as the internet or a telephone data network. In the case of, for example, a smartphone application (“App”) developer, an advertiser can provide the developer with its SDK for integration with the developer's App.
In online advertising where browsers and other web-based protocols are used to display ads, tracking ad interactions is made possible using Hypertext Markup Language (HTML) to send data across the many networks and servers that may be involved. However, some video player devices, including some mobile devices such as smartphones, do not always employ traditional browsers and may not use HTML. That is, video players are built on a variety of different technologies, each using their own instance of the technology. If ad servers want to serve ads to a variety of video players, they have to develop ad tags designed to display ads based on the technology of each video player they want to serve. Complicating matters is that multiple servers may be required as part of the process to serve ads, requiring each to provide specialized ad display information.
In order for publishers to serve ads across multiple video player platforms, it is desirable for the industry to come up with a set of common standards. This was realized early on in the video ad space, and the first versions of these standards were developed back in 2008, when the Interactive Advertising Bureau (IAB) introduced the first version of the Video Ad Serving Template (VAST). In 2009, the IAB introduced the Video Player-Ad Interface Definition (VPAID) and, more recently, the Digital Video Multiple Ad Playlist (VMAP) which, along with VAST, comprise the IAB Video Suite, which currently includes VAST 3.0, published Jul. 19, 2012, VPAID 2.0, released Apr. 10, 2012, and VMAP 1.0.1, released in July, 2014. The VAST 3.0, VPAID 2.0 and VMAP 1.0.1 specifications are incorporated herein by reference in their entireties.
The IAB Video Suite's specifications are designed to work together, as part of a thorough in-stream video advertising offering: The VAST specification provides a universal protocol for serving in-stream video ads, permitting ad servers to use a single ad response format across multiple compliant publishers/video players. The VPAID specification provides a communication protocol between ad units and video players that enables rich ad experiences and detailed event reporting back to advertisers. The VMAP specification provides a protocol that allows content owners to describe where ad breaks should be placed in their content when they do not control the video player or the content distribution outlet.
Essentially, VAST is a video ad-serving template that provides a uniform way for advertising data to be transferred from ad servers to video players independent of any technology. Using XML, VAST does for video ad serving what HTML does for browser-based ad serving. That is, just as HTML enables web browsers to display websites from any web server, VAST enables video players to display ads from any video ad server.
In general, the ad-serving process supported by VAST involves the video player requesting a video ad, displaying the VAST response and sending tracking information for ad impressions and other events back to the server. This can be done directly between the video player and one ad server (usually the publisher's) or between the video player and multiple ad servers. The ads may be in-stream video ads may that play before, after or in the middle of the publisher's content video (“linear ads”). Linear ads are typically served as video, but may also include static images, that play for a set duration at linear points along the timeline of the content video. They may play before the content video starts (pre-roll), at a break during the content video (mid-roll), or after the content video (post-roll). The ads may also be image or “overlay” ads overlaying content video while the contents is being played. (“nonlinear ads”). Nonlinear ads usually cover the top or bottom fifth of the content video and are typically text or static images that display for about 10-20 seconds.
Companion ads are served with linear or nonlinear ads, but are displayed outside the video player. They can serve as a “leave-behind” on the page after the video ad has ended and enable a more engaging experience for the user. A Companion Ad is commonly displayed as a standard banner or rich media ad, but can also be a skin that wraps the video ad experience. One or more Companion ads may be served with the originating video portion of the ad, or the Master Ad.
While VAST provides a common ad response format for video players to enable video ads to be served across all compliant video players, it does not provide stand-alone support for rich interactivity. VAST alone only supports relatively simple in-stream video ad formats that are not executable. These simple ad formats do not provide an interactive user experience, and do not allow the advertiser to collect rich interaction details. The introduction of VPAID standards allows compliant video players to display rich interactive media ads, also known as an “executable ad units.” Furthermore, VPAID offers Application Programming Interfaces (“APIs”) to interface video players with the executable ad units. In consequence, VPAID opens a line of communication between an executable ad unit and a video player, making it possible for the two to interact.
A Content Delivery Network (a/k/a “Content Distribution Network” and/or “CDN”) is typically a large, distributed system of servers deployed in multiple data centers across the internet. The goal of a CDN is to serve content to end-users with high availability and high performance. CDNs serve a large fraction of the internet content today, including web objects (text, graphics and scripts), downloadable objects (media files, software, documents), applications (e-commerce, portals), live streaming media, on-demand streaming media, and social networks.
Content providers, such as media companies and e-commerce vendors, can pay CDN operators to deliver their content to their audience of end-users. In turn, a CDN pays ISPs, carriers, and network operators for hosting its servers in their data centers. Besides better performance and availability, CDNs also offload the traffic served directly from the content provider's origin infrastructure, resulting in possible cost savings. In addition, CDNs provide the content provider a degree of protection from Denial of Service (“DOS”) attacks by using their large distributed server infrastructure to absorb the attack traffic. While most early CDNs served content using dedicated servers owned and operated by the CDN, there is a recent trend use a hybrid model that uses peer-to-peer (P2P) technology. In the hybrid model, content is served using both dedicated servers and other peer-user-owned computers as applicable.
Most CDNs are operated as an application service provider (“ASP”) on the internet (also known as on-demand software or software as a service). An increasing number of internet network owners have built their own CDNs to improve on-net content delivery, reduce demand on their own telecommunications infrastructure, and to generate revenues from content customers. This might include offering access to media streaming to internet service subscribers.
While SDKs have been proven to be valuable, there is room for improvement. One problem is the difficulty of integrating an advertiser's SDK with a publisher's video player. For example, a website publisher must integrate SDKs, sometimes from a number of different advertisers, into its video players before delivering them to the users. This can be a time consuming process, and must be repeated as new versions of the advertisers' SDKs are released. This can be even more daunting for App developers, who would have to update their apps to keep up with advertiser SDK updates. As a result, many publishers limit the number of SDKs that they will support, and may continue to use older, less effective SDKs rather than go through frequent updates of their video players.
These and other limitations of the prior art will become apparent to those of skill in the art upon a reading of the following descriptions and a study of the several figures of the drawing.